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"Requirements" 


http://www.dilbert.com/strips/connic/2006-01-29/ 
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Importance of Requirements 

Link: 

http://www.projectsmart.co.uk/docs/chaos-report.pdf 


Reason for Project Failure 

% of 

Responses 

Incomplete requirements 

13.1 

Lack of user involvement 

12.4 

Lack of resources 

10.6 

Unrealistic expectations 

9.9 

Lack of management support 

9.3 

Changing requirements 

8.7 

Lack of planning 

8.1 

System no longer needed 

7.5 
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Requirements 

Types: 

user requirements 

• what tasks the user can do with the system 

functional requirements (features) 

• what behaviors the system does or supports 

non-functional requirements (qualities) 

• how well the system should do what it does 

• e.g., response time, resource usage, availability 
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Requirements 

Types: 

external interfaces 

• e.g., interfaces to other hardware and software, 
data sources and sinks, formats, protocols 


physical setting 

• e.g., location, workspace, lighting, noise, temperatu 


developer constraint 


e.g., implementation technology, documentation 


Requirements 

Types: 

business requirements 

• why the system is needed 


business constraint 

• what the system or process must comply with 

• e.g., corporate policy, industry standard, 
government regulation 


Requirements 

Requirements should be: 
correct 

• requirements properly represent user needs 
complete 

• all possible scenarios are described 
consistent 

• requirements do not contradict each other 

clear 

• no ambiguities 

realistic 

• can be achieved by "mere mortals" 
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Requirements 

Also desired: 
traceable 

• can trace functionality and tests to the 
requirement being satisfied 


verifiable 


repeatable test(s) can be designed to show that 
the system fulfills the requirement 


Verifiable Requirements 

Verifiable? 


"The system shall have a good user interface." 


Verifiable Requirements 

Verifiable? 

"The system shall respond to the user in under one second 
for most tasks." 
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Verifiable Requirements 

Verifiable? 

"When the output state changes, it is logged in the event 
log." 
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Verifiable Requirements 

Verifiable? 

"The system shall be free of defects." 
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Requirements Activities 

Done iteratively: 

requirements elicitation 

• discover user needs 


requirements analysis 

• decide scope and priorities 

• study feasibility, create mockups 


requirements specification 

• detail the requirements in terms the users can 
understand 


Users 


Who is the "user"? 
primary 

• end user 

• with frequent hands-on use 
secondary 

• manager of end users 

• with occasional use, or via an assistant 

• 


tertiary 


owner of the system 

uses output, influences or makes funding decisions 


Users 


Some characteristics to consider: 
backg round 

• literacy and language 

• motivation to learn 

• domain knowledge 

• task familiarity 

• computer skills 

• attitude to computers and technology 
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Users 


Some characteristics to consider: 

perceptual, motor, and tactile abilities 

• seeing and hearing difficulties 

• fine motor skills with input devices 

physical 

• height and strength (for kiosk design) 

• hand/finger size (for mobile device design) 

• health, age, and gender 

social 

• relationships with peers 

• culture 
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Users 


Kinds of use: 

infrequent use / novice user 

• need wizards 

• need clear prompts, error handling 

frequent use / expert user 

• need keyboard shortcuts 

• need customization, programmability 


Users 


Some issues to consider: 

users cannot always express what they want 

• but they often know what they do not like 
users may not know what is possible 

• what is technically and economically feasible? 
users stick to what they ... 

• know already works, or have always done 
users may fear job losses 

• leads to non-constructive participation 
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"Users" 


http://www.dilbert.com/strips/connic/1994-09-22/ 
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Users 


"Innovator's dilemma": 

as the user base for an application grows, there is a 
tendency for developers to focus on this increasingly 
expert (and vocal) group of users 


the system becomes more sophisticated 
development becomes "optimized" for them 


Users 


"Innovator's dilemma": 

potential new users need "less" 

experts don't want their app "dumbed down" 


competitor attracts the new users with a simpler "good 
enough" app 


original app loses market share due to disruption from the 
low end 
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"Listening to Users" 



© Fox 


"Listening to Users" 


http://theoatmeal.com/comics/design_hell 
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Understanding 


Tips: 

manage expectations 

• be clear and honest about claims 

• avoid surprises, disappointments, hype 
involve the user 

• build tangible prototypes to gain feedback 

• more likely to forgive problems if they are 
involved 

establish a glossary 

• terminology used in the application domain 
(not programming domain) 


User Requirements 
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Identifying Tasks 

Study what tasks users do: 

what is the goal and context? 
what information is needed? 
what are the steps? 
who does the user work with? 
why is it done this way? 


Identifying Tasks 

Scenario: 

an informal narrative 

personal and concrete, but not particularly general 


use the scenario to understand existing goals, task flow, 
and possible irritants 
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Scenario 


Example: 

“I want to track the calories for a meal, so I consult the 
USDA Nutrient database. I want to look up 'Pacific salmon' 
so I enter that as the keywords. Item not found! So I enter 
'salmon' and try again. That works, but I get 46 items, 
including salmonberries and even cloudberries. Why? I 
choose 'fish, salmon, sockeye, cooked, dry heat', then 
figure 2.5 x 100 g units for my item, and scan the table to 
see 422 kcal in the energy row." 
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Specifying Tasks 

Use Cases: 

capture the goal, conditions, and steps of a coherent 
interaction between the actor(s) and the software system 


more general than a specific scenario 


written from a "user" point-of-view 
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Defining Use Cases 

Stages: 

identify the actors 

• consider different user roles and external systems 
define use cases 

• include all cases of use 
refine use cases 

• consider exceptional conditions and qualities 
relate use cases 

• consider inclusion and extension dependencies 
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MO 


Identify the Actors 

use case diagram 



boundary of the system 
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Identify the Actors 

Actor generalization: 



/\ 

User 




/\ 

Meal 

Planner 



Administrator 





Define/Refine Use Cases 

Example: 

Use Case Name 
Participating Actors 

Goal 
Trigger 
Precondition 
Postcondition 


SearchForNutritionlnfo 

Meal Planner (primary) 

Meal Planner finds nutrition information 

Meal Planner chooses the Search option 

Meal Planner knows food name and 
amount. 

On success, nutrition information displayed. 
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Define/Refine Use Cases 

Example: 

Basic Flow 1 

2 

3 

4 

5 

6 
7 


user point of view 


System prompts Meal Planner to enter 
keywords. 

Meal Planner submits keywords. 

System lists matching foods, prompting for 
a selection. 

Meal Planner browses and selects a food. 

System prompts for food weight in units of 
100 g. _ 

Meal Planner enters food units. 

System presents nutrition data for the 
amount of food. 

avoid implementation specifics 










Define/Refine Use Cases 

Example: 

Exceptions 3 

3.1 

3.2 
7 


If there are no matching foods 

System displays an error 

System returns to step 1 

If given food units is non-numeric, use 0 
and proceed 
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Define/Refine Use Cases 

Example: 

Qualities 


Constraints 
Includes 
Extends 
Related Artifacts 

Notes 
Open Issues 


System responds in under 2 s for list of 
matching foods and for nutrition data on a 
specific food. 


Use USDA nutrition data. 
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Essential Use Case 


SearchForNutritionlnfo 


User Intention (Meal 

Planner) 

System Responsibility 

Initiate search. 



Request keywords. 

Submit keywords. 



List matching foods to 
select. 

Select a food. 



Request food units. 

Enter food units. 



Present nutrition data. 
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Exercise 

C Question: 

What is a basic flow for the task of 
withdrawing cash from a bank machine? 
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Relate Use Cases 



Inclusion: 

a use case may include another use case 
(for necessary, shared behavior) 




«include» 
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Relate Use Cases 


Extension: 

a use case may be extended by another use case (for 
optional or exceptional behavior) 
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Relate Use Cases 


Use case generalization: 

a use case may be a specialization of a more general use 
case 



Do ATM 
Transaction 




Make 

Withdrawal 









User Stories 
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Specifying Needs 



Write down all the 
requirements. 


Users only get what 
was written . 


Agile method: less writing, more talking 


Users get what 
they want. 
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Specifying Needs 

User story: 

written description of what a user wants to achieve with 
the system 


As a guest, I want to 
reserve a hotel room. __ 

rAsQ _ guestTlwantTosee 

a list of room amenities. 

As a conference planner, 

-1 want to see meeting 
room capacities. 


on index cards 


Typical forms: 

As a «user role »> 
I want «goal». 

As a «user role »> 
I want «goal», 
so that «reason». 
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Defining User Stories 

Tips: 

describe what not how 

• avoid technical details or choices of 
technologies, 

unless it is a development constraint 


avoid epics for near-term needs 

• better to split up huge stories into more, 
smaller stories (but not too small) 


Defining User Stories 

Tips: 

prioritize user stories 

• discuss with the user what they find of most 
value, and stage development on that first 


can attach an effort estimate to complete 

• normally sized to take days, not many weeks 


use stories to plan development tasks 

• create work items in the iteration plan 
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"SMART Work Items" 


s 

Specific 

M 

Measurable 

A 

Achievable 

R 

Relevant 

T 

Time Boxed 


Link: 

http://xpl23.com/articles/invest-in-good-stories-and-smart-tasks/ 
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"INVEST in Good Stories" 


I 

Independent 

N 

Negotiable 

V 

Valuable 

E 

Estimable 

S 

Small 

T 

Testable 


Link: 

http://xpl23.com/articles/invest-in-good-stories-and-smart-tasks/ 


50 









Testable User Stories 


Front of the card: 


As a meal planner, I want 
to see nutrition 
information for a given 
amount of a given food. 
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Testable User Stories 


Back of the card: 


Link: 

http://xprogramming.com/articles/ 

expcardconversationconfirmation/ 


acceptance tests 


Try it for 250 g 0 f 

aked Pacif ic salmon. 
J r Y 'T with a missing 
food name. 

Try it with a non¬ 
numeric amount. 










"User Story" 


http://www.dilbert.com/strips/connic/2003-01-10/ 
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Augmenting 

Requirements 



Augmenting Requirements 

Can add other descriptions, for example: 
use cases to user stories 

data schemas 

sample input and output 

user interface mockups and storyboards 

grammars (language syntactic/lexical structure) 



<identifier> :: = 

<letter> { <letter> | <digit> } 


■> 


digit 
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State Models 


Modeling behavior: 

used in formally modeling the behavior of a specific object 
in response to external events 
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UML State Diagram 

Modeling behavior: 

states in which something can be in 

• a situation represented by attribute values 
directed transitions between states 

• triggered by events, input, time, messages, etc. 


start / toggle := true 


transition 




initial state 


state 


stop / toggle := false 
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UML State Diagram 






















UML State Diagram 

States: 


/ -\ 

state name 

s_ * 


r 


\ 


state name 



activities 


V 


y 


( \ 

state name 


variables 


activities 

\ _ J 
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UML State Diagram 

Activities in states: 


entry / 
action 

perform action when entering 
state 

do / action 

perform action while in state 

exit / action 

perform action when exiting 
state 


r 


Timing 


do / countdown 


timeout 


A 


Ready 


entry / beep 


v 
















UML State Diagram 

Activities in states: a/so called an 

internal transition 


trigger / 
action 

when trigger occurs, perform 
action 

SettingDay 

button2 

r \ 

SettingMonth 

entry / 

start day blink 
buttonl / 
increment day 
exit / 

stop day blink 

entry / 

start month blink 
buttonl / 
increment month 
exit / 

stop month blink 



V 


button3 
















UML State Diagram 

Transitions. general form of transition label 

trigger [ guard ] / effect 

if in a current state, 
and trigger occurs, 

and guard constraint (if any) is true ... 

then perform state exit actions (if any), 
perform corresponding transition effect (if any), 
perform new state entry actions (if any); 


otherwise, stay at current state 



Room Planner 

Canvas: 

to place and move items 


Mouse events: 
click 

press/drag/release 


Item type menu: 

choices of fixtures and furn 




















Room Planner 


Placing an item: 

user clicks on canvas outside any item 

• system shows the item type menu 
user chooses an item type from the menu 

• system hides the item type menu 
user clicks on the canvas 

• system draws item of the chosen type 
at the mouse location 


Room Planner 


Moving an item: 

user presses inside an item 

• system highlights item 
user drags item 

• system shows moving item 
user releases mouse 

• system puts item at new location 

• system removes item highlighting 


Room Planner 

States: 

waiting 

• nothing happening 

moving 

• moving item to new position 

choosing 

• choosing item type from menu 

placing 


placing chosen shape 


/-\ 

Choosing A 

s_ ^ 


click 

[outside any item] / 
show menu 


press 

[inside item F] / 
current := F; 
highlight current 



Moving 


current 

(x, y) 


■> 



choose 


item type / 
hide menu 

— 

* - \ 

Waiting 

t ^A 
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release / 

unhighlight 

current 


click / 

draw item at 
mouse location 


erase current; 
update current.x; 
update current.y; 
draw current 



drag (x, y) 
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UML State Diagram 

Tips: 

check for completeness 

• states reachable? 

• missing transitions? 

• events not considered? 

• unforeseen situations? 

check for dangerous situations 

• e.g., exiting without having saved edits 


UML State Diagram 

Tips: 

check for consistency 

• similar interactions have similar effects? 

• effects are visible and give good feedback? 

aid the user 

• is undo appropriate, in a given state? 

• is cancel or escape appropriate? 

• is invoking help appropriate? 


More Information 


Books: 

The Essence of Object-Oriented Programming with Java 
and UML 


• B. Wampler 

• Addison-Wesley, 2002 


UML Distilled 

• M. Fowler 

• Addison-Wesley, 2003 


70 


More Information 


Books: 

User Stories Applied 

• M. Cohn 

• Addison-Wesley, 2004 

More About Software Requirements 

• K. Wiegers 

• Microsoft, 2006 


More Information 


Books: 

Software Engineering: Theory and Practice 

• S.L. Pfleeger 

• Prentice-Hall, 2009 


More Information 


Links: 

Use Cases, Ten Years Later 

• http://alistair.cockburn.us/Use+cases%2c+ten+yec 
later 


Effective User Stories for Agile Requirements 

• http://www.mountaingoatsoftware.com 

/presentations/52-effective-user-stories-for-agile-re 
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